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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is incorrect. A correct 
statement of the status of the claims is as follows: 

Claims 1-18, 20-30, 32-35 and 38-41 have been finally rejected. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 
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(8) Evidence Relied Upon 



US 6,219,648 B1 



JONES ET AL. 



4-2001 



US 2002/0123983 A1 



RILEY ETAL 



9-2002 



Robert W. Scheifler and Jim Gettys, The X Window System, ACM Transactions of 
Graphics, Vol. 5, No. 2, pp. 79-109 (April 19, 1986) 

Mike Tsykin, Automated Service Level Reporting: Experience of Implementation, Fujitsu 
Australia, Ltd. pp. 1-12 (2000) 
Official Notice 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 



1. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed 
or described as set forth in section 102 of this title, if the differences between the 
subject matter sought to be patented and the prior art are such that the subject 
matter as a whole would have been obvious at the time the invention was made 
to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was 
made. 



2. Claims 1,12 and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Jones et al. (US 6,219,648) in view of Scheifler et al. The X Window 
System, ACM Transaction on Graphics, Vol. 5, No. 2, April 1996 and further in 
view of Tsykin, Automated Service Level Reporting: Experience of 
Implementation, Fujitsu Australia, 2000. 



Claim Rejections - 35 USC § 103 
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Claim 1: 

As per claim 1, Jones et al. teaches a method for monitoring service tickets for 
information technology service providers to ensure that levels of service required to be 
provided to a customer pursuant to an agreement between the customer and a service 
provider, are met, the method comprising: 

• inspecting a service ticket in a database to determine a deadline for when 
a problem associated with the service ticket must be resolved, (col. 3, 
lines 11-20; col. 5, line 60-col. 6, line 2; col. 6, line 35-col. 7, line 61; col. 8, 
line 55-col. 10, line 64 teaches time intervals corresponding to escalation 
levels for a trouble ticket; the escalation levels being defined based on the 
trouble ticket remaining unresolved for a time exceeding user specified 
time intervals; a ticket reporting and tracking system for inputting trouble 
tickets and keeping track of the ticket status in the repair process, where 
the information contained in the trouble report is stored in the ticket 
reporting and tracking system, data files are formatted into data records 
and send to a managing module, where the records are stored in memory 
and then evaluated against a configuration data file to determine if an alert 
should be transmitted); 
Jones et al. teaches "the escalation levels being defined based on the trouble ticket 
remaining unresolved for a time exceeding user specified time intervals; (Jones et al., 
col. 5, lines 63-65); a ticket reporting and tracking system for inputting trouble tickets 
and keeping track of the ticket status in the repair process (Jones et al. col. 6, lines 35- 
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37). Jones et al. does not expressly teach that the deadline based upon a contractually 
determined severity of the problem and a corresponding contractually required time for 
resolution of the problem. However, Tsykin in an analogous art of monitoring service 
tickets (e.g., automated service level reporting) for the purpose of determining severity 
and required time for resolution of the problem based upon a contract (Tsykin, page 10, 
Figure 12) as shown does: 

• with the deadline based upon a contractually determined severity of the 
problem and a corresponding contractually required time for resolution of 
the problem (page 10, Figure 12, which teaches a deadline based upon a 
contract (e.g., Service Level Agreement, SLA) which is old and well known 
that SLA is a negotiated agreement between two parties where one is the 
customer and the other is the service provider. Figure 12 teaches item 
"Help Desk Response" with a determined severity of the problem "Severity 
1, Severity 2 and Severity 3" and corresponding contractually required 
time for resolution of the problem "Severity 1 : < 30 min, Severity 2: < 2 hrs 
and Severity 3: < 2 hrs of next shift"); 
Therefore, it would have been obvious to one of ordinary skill in the art to modify Jones 
et al., to include the teaching of Tsykin because the claimed invention is merely a 
combination of old elements, and in the combination each element merely would have 
performed the same function as it did separately, and one of ordinary skill in the art 
would have recognized that the results of the combination were predictable. 
Further, Jones et al., teaches: 
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• displaying, on a display device at the help desk, a graphical display 
populated with representations of service tickets that have reached a 
predetermined percentage of the time before their due date (col. 5, lines 
51-53, which teaches that "the notification comprises an alphanumeric or 
digital page, an e-email message, or an X-Windows terminal display 
message." Where through an X-Windows terminal display "[t]he 
notification" which it "may contain various information, including the trouble 
ticket number, an escalation level, the date and time the ticket was first 
entered into the WFA system, the service type having trouble, customer 
name, current status of the ticket" (e.g., a predetermined percentage of 
the time before their due date) "and the identification (e.i. initials) of the 
technician involved in the service restoration effort."); 
Jones et al. teaches the use of X-Windows system to display graphically the notification 
to a user with information related to a trouble ticket (Jones et al. col. 5, lines 49-60). 
Jones et al. does not expressly teach that through the X-Window system a graphical 
display is populated with representations of service tickets as claimed. However, 
Scheifler in an analogous art of displaying user graphical interfaces through an X- 
Windows system for the purpose of enabling a user to modify an existing X-Windows 
system to populate a representation of service tickets (Scheifler et al, page 79, 1 st H) as 
shown does, where Scheifler et al. teaches that a X-Windows system enables a user "to 
build applications and to manage desktop" and it provides "a wide variety of application 
and user interfaces to be built easily" (Scheifler et al, page 79, 1 st H) . 
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Therefore, it would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify Jones et al. X- Windows system as taught by Scheifler et al. to 
graphically display a representation of tickets that have reached a predetermined 
percentage of the time before their due date because Scheifler X-Window system 
"provides high performance, high-level, device-independent graphics" (e.g. a graphical 
display). In addition, "desktop management can be custom-tailored to individual 
environments" (e.g., to display graphically a representation of tickets) (Scheifler et al, 
page 79, 1 st If). 

Furthermore, Jones et al disclose: 

• determining a deadline approaching alert time at which a help desk user 
must be notified that the deadline for resolving the problem must be met 
(col. 3, lines 11-20; col. 5, line 60-col. 6, line 2; col. 6, line 35-col. 7, line 61 
teaches time intervals corresponding to escalation levels for a trouble 
ticket; the escalation levels being defined based on the trouble ticket 
remaining unresolved for a time exceeding user specified time intervals); 

• and alerting the help desk user that the deadline for resolving the problem 
is approaching when the deadline approaching alert time is reached (col. 
11, line 13-col. 12, line 30 teaches when the alerting criteria for a ticket is 
satisfied, then notification should be sent to the appropriate management 
or personnel). 

As per claim 12, it recites a computer program product in a computer readable media 
for use in a data processing system for performing the methods of claim 1 . Since Jones 
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et al. teaches a computer program product in a computer readable media for use in a 
data processing system (col. 6, lines 5-35), claim 12 is rejected for the same reasons 
set forth above in claim 1 . 

As per claim 23, it recites a system in a computer readable media for use in a data 
processing system for performing the methods of claim 1 . Since Jones et al. teaches a 
system in a computer readable media for use in a data processing system (col. 6, lines 
5-35), claim 23 is rejected for the same reasons set forth above in claim 1 . 
3. Claims 2-1 1 , 13-18, 20-22, 24-30, 32-33, 34-35 and 39-40 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Jones et al. (US 6,219,648) in both 
view of Scheifler et al. The X Window System, ACM Transaction on Graphics, 
Vol. 5, No. 2, April 1996 and Tsykin, Automated Service Level Reporting: 
Experience of Implementation, Fujitsu Australia, 2000 as applied to claims 1, 12 
and 23 above and further in view of Riley et al. (US Pub. No. 2002/0123983 A1) 
and Official Notice. 
Claim 2 

As per claim 2, Jones et al. teaches: 

• determining a status update interval for the service ticket (col. 7, lines 19- 
39 teaches the application receiving reports on a time interval); 

• and responsive to a determination that the problem has not been resolved 
by the deadline, determining a first status update alert time to alert the 
help desk user (vol. 7, lines 19-61 teach that the interval should be 
predefined and publicly known because a configuration data file for 



Application/Control Number: 10/615,054 Page 9 

Art Unit: 3623 

alerting contains time periods for alerting based upon this interval where 
once the time duration of other alerting criteria has been satisfied, the 
module requests an alert to be sent to the appropriate personnel). 
Jones et al. does not expressly teach alerting the help desk user to then send a status 
update to the customer. However, Riley et al. in an analogous art of implementing 
service desk capability for the purpose of sending a status update to the customer 
(paragraphs 136-137), Riley et al. teaches alerting the help desk user to send a status 
update to the customer (paragraphs 136-137 teach the exceeding a target time and 
sending a notification to a personnel who will be assign the problem, where paragraph 
144 teaches that as service requests are escalated, or as they exceed target time and 
are assigned a higher tier operator in which notifications are sent to the new personnel, 
the Service Desk, or the personnel, needs to communicate the status with the 
customer). 

It would have been obvious to one of ordinary skill in the art to include in the method 
monitoring progress of customer generated trouble tickets of Jones et al. the ability to 
send a status update to the customer in response to ticket escalation as taught by Riley 
et al. since the claimed invention is merely a combination of old and well known 
elements, and in the combination, each element merely would have performed the 
same function it did separately, and one of ordinary skill in the art would have 
recognized that the results of the combination were predictable. 
Claim 3: 
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As per claim 3, Jones et al. teaches alerting the help desk user as recited above in 
claim 1. 

However, Jones et al. does not expressly teaches alerting the help desk user that a 
status update is approaching when the first status update alert time occurs. Riley et al. 
teaches alerting the help desk user that a status update is approaching when the first 
status update alert time occurs (paragraph 144). 

It would have been obvious to one of ordinary skill in the art to include in the method 
monitoring progress of customer generated trouble tickets of Jones et al. the ability to 
send an alert that a status update is necessary as taught by Riley et al. since the 
claimed invention is merely a combination of old and well known elements, and in the 
combination, each element merely would have performed the same function it did 
separately, and one of ordinary skill in the art would have recognized that the results of 
the combination were predictable. 
Claim 4: 

As per claim 4, Jones et al. teaches responsive to a determination that the problem has 
not been resolved after a time has passed, determining a time to alert the help desk 
user as recited above in claim 1 . However, Jones et al. does not teach the time being a 
status update time or determining a time to alert the help desk user that a time to 
provide a new status update to the customer is approaching and alerting the help desk 
user prior to the time to provide the new status update. 

Riley et al. teaches time being a status update time and determining a time to alert the 
help desk user that a time to provide a new status update to the customer is 
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approaching and alerting the help desk user prior to the time to provide the new status 
update (paragraphs 77-82 teach reminding personnel when to escalate incidents, when 
to provide status information to users, and when service levels are not being met; Fig 12 
teaches notifying or alerting of escalation and contacting the customer as part of the 
whole service request escalation process, or rather alerting of escalation, which 
includes a new status update). 

It would have been obvious to one of ordinary skill in the art to include in the method 
monitoring progress of customer generated trouble tickets of Jones et al. the ability to 
alert of a status update time and providing new status updates to the customer as 
taught by Riley et al. since the claimed invention is merely a combination of old and well 
known elements, and in the combination, each element merely would have performed 
the same function it did separately, and one of ordinary skill in the art would have 
recognized that the results of the combination were predictable. 
Claim 5: 

As per claim 5, Jones et al. teaches alerting the helpdesk user that the deadline for 
resolving the problem is approaching when the deadline approaching alert time is 
reached comprising sending an alert wherein the alert includes an identity of the service 
ticket (col. 11, line 35-col. 12, line 11 teach the alert message or notification including 
the ticket number). However, Jones et al. does not expressly teach the alert including 
the deadline for when a problem associate with the service ticket must be resolved. 
Riley et al. teaches an alert including the deadline for when a problem associated with 
the service ticket must be resolved (paragraph 79 teaches reminding personnel when to 
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escalate incidents and when service levels are not being met; paragraph 143 teaches 
as soon as a problem cannot be resolved in the targeted service levels is will be 
escalated, service requests are escalated if SLAs are likely to be impacted, where the 
escalation should be configured to occur well before the actual SLA targets are passed, 
escalation includes the notification of the assignee and the next level of management, 
Fig. 12). 

It would have been obvious to one of ordinary skill in the art to include in the method 
monitoring progress of customer generated trouble tickets of Jones et al. the ability to 
include the deadline as taught by Riley et al. since the claimed invention is merely a 
combination of old and well known elements, and in the combination, each element 
merely would have performed the same function it did separately, and one of ordinary 
skill in the art would have recognized that the results of the combination were 
predictable. 
Claim 6: 

As per claim 6, Jones et al. teaches an alert as recited above in claim 1 and further the 
alert being in a window (col. 2, lines 15-33). However, Jones et al. does not expressly 
teach the alert comprises a pop-up window. Riley et al. teaches an alert comprising a 
pop-up window (paragraph 137). 

It would have been obvious to one of ordinary skill in the art to include in the method 
monitoring progress of customer generated trouble tickets of Jones et al. a pop-up 
window as taught by Riley et al. since the claimed invention is merely a combination of 
old and well known elements, and in the combination, each element merely would have 
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performed the same function it did separately, and one of ordinary skill in the art would 
have recognized that the results of the combination were predictable. 
Claim 7: 

As per claim 7, Jones et al. teaches an alert to the help desk user's data processing 
system as recited in claim 1. Further Riley et al. teaches the alert being a pop-up 
window as recited above in claim 6. However, neither Jones et al. nor Riley et al. 
expressly teach the pop-up window is displayed on top of all other windows that are 
open on the data processing system. Examiner takes Official notice that a pop-up 
window being displayed on top of all other windows that are open on a data processing 
system is old and well known in the art. Thus, it would have been obvious to one of 
ordinary skill in the art to include the pop-up window being displayed on top of all other 
windows in order to more efficiently generate a notification to alert personnel or 
management that outages exist that have exceeded predefined time limits of intervals 
(see Jones et al., col. 1 , line 65-col. 2, line 2). 
Claim 8: 

As per claim 8, Jones et al. teaches the alert comprises an audio alert (col. 2, lines 15- 
33 teaches the alerts being page notifications, which are audio alerts). 
Claim 9: 

As per claim 9, Jones et al. teaches the alert comprises a graphical alert (col. 2, lines 
15-33 teach the alerts being alphanumeric, e-mail, an X-window terminal message, or 
graphical alerts). 
Claim 10: 
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As per claim 10, Jones et al. teaches a deadline for when a problem associated with 

the service ticket must be resolved as recited in claim 1. However, Jones et al. does 

not expressly teach the deadline for when a problem associated with the service ticket 

must be resolved is determined by consulting a ticket severity table. 

Riley et al. teaches teach the deadline for when a problem associated with the service 

ticket must be resolved is determined by consulting a ticket severity table (paragraphs 

116-123). 

It would have been obvious to one of ordinary skill in the art to include in the method 
monitoring progress of customer generated trouble tickets of Jones et al. the ability to 
determine a deadline by consulting a ticket severity table as taught by Riley et al. since 
the claimed invention is merely a combination of old and well known elements, and in 
the combination, each element merely would have performed the same function it did 
separately, and one of ordinary skill in the art would have recognized that the results of 
the combination were predictable. 
Claim 11: 

As per claim 11, Jones et al. does not teach the ticket severity table is populated in 
accordance with a level of service agreement between the customer and the information 
technology provider. Riley et al. teaches the ticket severity table is populated in 
accordance with a level of service agreement between the customer and the information 
technology provider (paragraphs 1 1 6-1 23; 61 ; 81 ). 

It would have been obvious to one of ordinary skill in the art to include in the method 
monitoring progress of customer generated trouble tickets of Jones et al. the ability to 
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determine a deadline by consulting a ticket severity table populated in accordance with 
a level of service agreement as taught by Riley et al. since the claimed invention is 
merely a combination of old and well known elements, and in the combination, each 
element merely would have performed the same function it did separately, and one of 
ordinary skill in the art would have recognized that the results of the combination were 
predictable. 

Claims 13-18 and 20-22: 

As per claims 13-18 and 20-22, they recite a computer program product in a computer 
readable media for use in a data processing system for performing the methods of 
claims 2-11. Since Jones et al. teaches a computer program product in a computer 
readable media for use in a data processing system (col. 6, lines 5-35), claims 13-18 
and 20-22 are rejected for the same reasons set forth above in claims 2-1 1 . 
Claims 24-30 and 32-33: 

As per claims 24-30 and 32-33, they recite a system in a computer readable media for 
use in a data processing system for performing the methods of claims 2-1 1 . Since 
Jones et al. teaches a system in a computer readable media for use in a data 
processing system (col. 6, lines 5-35), claims 24-30 and 32-33 are rejected for the same 
reasons set forth above in claims 2-1 1 . 
Claim 34: 

As per claim 34, Jones et al. teaches a system for monitoring service tickets in order to 
provide reminders to a help desk user of impending times for actions, the times actions 
being provided according to a level of service required to be provided to a customer 
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pursuant to a contract between the customer and a service provider, the system 
comprising: 

• a monitoring server; a database; and a help desk client (col. 6, line 5-col. 
8, line 32 teach a tracking system, or a monitoring server, storing the 
trouble tickets in data records, or a database; and col. 11, lines 35-54 
teach alerting going to the appropriate personnel, or a help desk client); 

• the database stores tickets and information regarding ticket types, ticket 
severities; for actions to be performed for each of the ticket types and 
ticket severities (col. 11, lines 35-66 teach the report information 
containing information including type of service required, or ticket type, 
ticket duration, status, position, escalation levels, or time for actions to be 
performed for each ticket, which includes ticket type; col. 15, lines 35-44 
teach that the severity of repair work can be indicated in the report as 
well); 

• the monitoring server monitors tickets in the database, determines when 
time for actions are approaching, and sends alerts to the help desk client 
alerting the help desk user that a time to take a specified action is 
approaching (col. 3, lines 11-20; col. 5, line 60-col. 6, line 2; col. 6, line 35- 
col. 7, line 61 teaches time intervals corresponding to escalation levels for 
a trouble ticket; the escalation levels being defined based on the trouble 
ticket remaining unresolved for a time exceeding user specified time 
intervals; col. 11, line 13-col. 12, line 30 teaches when the alerting criteria 
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for a ticket is satisfied, then notification should be sent to the appropriate 
management or personnel); 

• the help desk client displays active tickets to a help desk user and 
provides alerts received from the monitoring server to the help desk user 
(col. 5, line 50-60 teaches displaying notifications including trouble ticket 
number, an escalation level, date and time, service type, status, etc). 

Jones et al., teaches that the invention "is to satisfy customer requirements for timely, 
proactive and documented internal escalations" (page 2, lines 9-11). Jones et al., does 
not specifically teach the following limitation. However, Riley et al., in an analogous art 
of implementing service desk capability for the purpose of storing contractually required 
times (e.g., service level agreement) (Figures 2 and 6, If 01 1 6-0121) as shown does: 

• based on the contract and corresponding contractually required times 
(Figure 2 illustrates a "Central Service Desk Repository", which stores 
information related to problems and solutions and Figure 6, U 0116-0121, 
illustrate a service request logging and categorization, block 69, "Assign 
Priority to Service Request" where "the operator analyzes the service 
request in order to prioritize it. The resulting prioritization is used to 
classify the request against all other requests made by the Service Desk 
customers and determines the speed in which the service request should 
be handled" (e.g., contractually required times) "(according to defined 
Service Level Agreements or SLAs)." Further, "[t]he type of information 
necessary for assigning priority can include: [t]he service request's impact, 
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the service request's severity, the criticality of the business function 
affected, the resolution urgency. The meaning of each of these terms will 
be adjusted to fit the organization, but each should be clearly defined and 
documented" (e.g., Service Level Agreement or SLAs) which is old and 
well known that SLA is a negotiated agreement between two parties 
where one is the customer and the other is the service provider where the 
level of service is formally defined); 
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the 
invention to store contractually required times (e.g., service level agreement), as taught 
by Riley et al., to improve Jones et al., thereby giving the predictable result of setting out 
"the services to be performed and the target service levels to be achieved. These SLAs 
are designed for the user community and are written with the Service Desk customers in 
mind." (Riley et al., U 0032). 
Claim 35: 

As per claim 35, Jones et al. teaches a time associated with the system (col. 5, line 50- 
col. 6, line 34). However, Jones et al. does not expressly teach the time determined 
using a centralized clock. Examiner takes Official notice that utilizing a centralized clock 
when time is recorded in a computer system is old and well known in the art. Thus, it 
would have been obvious to one of ordinary skill in the art at the time of the invention to 
utilize a centralized clock in order to record the time as taught by Jones et al. in order to 
more accurately record the time of a trouble ticket and to track data modification (e.g., 
log files) related to the trouble ticket (Jones et al. col. 3, lines 5-10). 
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Claim 39: 

Jones et al. disclose the following limitation: 

• wherein the active tickets displayed are only those that have reached a 
predetermined percentage of the time before their due date (col. 1 lines 
65-67-col.2 lines 1-2 and col. 2, lines 23-34, which teaches that a 
notification is sent through the X-Windows system which is fully 
customizable as discussed above "to alert key personnel or management 
that outages (i.e. troubles) exist that have exceeded predefined time limits 
or intervals" (a predetermined percentage of the time before their due 
date). Jones et al. teaches that the notification display only those ones 
that have exceeded a predefined time limit or intervals.); 

Claim 40: 

Jones et al. disclose the following limitation: 

• wherein the percentage of time is 75% of the time specified in an 
associated LOS (col. 5, lines 41-44, which teaches that it "provides a 
management tool to alert recipients of trouble tickets having exceeded 
predefined time interval(s)" (e.g., a percentage of time) "without service 
resolution or repair"); 

Jones et al. does not expressly teach that the percentage of time is 75% of the time 
specified. However, Examiner takes Official Notice that it is old and well known in the 
art to set a predetermined period of time (e.g., 75% or less than 75%) in order to comply 
with the associated level of service by alerting recipients of trouble tickets. Therefore, it 
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would have been obvious to a person of ordinary skill in the art at the time of the 
invention to set a 75% or less than 75% of the time specified (e.g., a predefined time 
interval) to improve Jones et al. thereby giving the predictable result of performing 
equally well by specifying a different percentage of time (e.g., less than 75%) in order to 
comply with an associated level of service by completing a service resolution or repair in 
less time. 

4. Claims 38 and 41 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Jones et al. (US 6,219,648) in view of Scheifler et al. The X Window 
System, ACM Transaction on Graphics, Vol. 5, No. 2, April 1996 in view of Riley 
et al. (US Pub. No. 2002/0123983 A1) as applied to claims 1-37 and 39-40 above 
and further in view of Quercia et al. The Definitive Guides to the X Window 
System, O'Reilly & Associates, Inc. Volume Three, Motif Edition, 1993. 

Claim 38: 

Jones et al. teaches the use of X-Windows system to display graphically the notification 
to a user. The combination of Jones et al. and Scheifler et al. does not teach the 
following limitation. However, Quercia et al. in an analogous art of user graphical 
interfaces tool for the purpose to graphically display information in a grid format (Figure 
6-7, page 147) as shown does: 

• wherein the activities tickets are displayed in a grid (Figure 6-7, page 147, 

which it illustrates that X-windows system enables a user to graphically 

display information in a grid format); 
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Therefore, it would have been obvious to one of ordinary skill in the art at the time of the 
invention to modify the X-Windows system to display the activities ticket in a grid as 
taught by Quercia et al., to improve the combination of Jones et al. and Scheifler et al., 
thereby giving the predictable result of providing an user friendly graphical 
representation of the activities tickets status, because X-Windows system allows "to 
display certain information about the individual characters" (Quercia et al., page 147, 2 nd 

ID- 
Claim 41: 

Jones et al. teaches the use of X-Windows system to display graphically the notification 
to a user. The combination of Jones et al. and Scheifler et al. does not teach the 
following limitation. However, Quercia et al. in an analogous art of user graphical 
interfaces tool for the purpose to minimize the display (page 8, Figure 1-2,) as shown 
does: 

• wherein the display may be minimized at the election of the user (page 8, 
Figure 1-2, which it illustrates a "Minimize button" which is old and well 
known in the art); 

Therefore, it would have been obvious to one of ordinary skill in the art at the time of the 
invention to enable a user to minimize a display as taught by Quercia et al., to improve 
the combination of Jones et al. and Scheifler et al., thereby giving the predictable result 
of allowing a user to minimize the display through a minimize button. 
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(10) Response to Argument 

In the Appeal Brief, Appellant presents the following arguments: 
Independent Claim 1: 

1 ) Appellant argues that Jones et al., fails to disclose that the customer is 
consulted or has any input regarding the selection of the deadline, 

as one of skill in the art reading Jones et al., would conclude that the 
determined deadline is determined entirely and exclusively by the 
service provider without regard to the customer to whom service is to be 
provided. 

2) That as apparently conceded by the Examiner, Jones et al., fails to 
disclose inspecting a service ticket in a database to determine a 
deadline for when a problem associated with the service ticket must be 
resolved, where the deadline is based upon a contractually determined 
severity of the problem and a corresponding contractually required time 
for resolution of the problem. 

3) Jones et al., fails to, however, disclose displaying on a display device a 
graphical display populated with representations of service tickets that 
have reached a predetermined percentage of time before their due 
date. 

4) Jones et al., further fails to disclose determining a deadline 
approaching alert time at which a help desk user must be notified that 
the deadline for resolving a problem must be met. 
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5) Jones et al., fails to disclose determining a deadline approaching alert 
time at which a help desk user must be notified that a deadline that is 
based upon a contractually determined severity of the problem is 
approaching. 

6) Tsykin fails to, however, disclose inspecting a service ticket to 
determine a deadline that is based upon a contractually determined 
severity of the problem and a corresponding contractually required time 
for resolution of the problem. In this regard, Tsykin merely discloses 
reporting the percentage of responses that conform to SLA 
requirements, not setting deadlines. Tsykin also fails to disclose or 
render obvious the selection of an additional deadline approaching 
deadline. 

7) The Office Action fails to show why one of skill in the art in possession 
of the cited references would have derived determining a deadline 
approach alert time at which a help desk user must be notified that the 
deadline, which is contractually determined for resolving the problem, 
must be met. Neither Jones et al., nor Tsykin discloses determining a 
deadline approaching alert time in that neither the hypothetical 
combination of these references nor any reasoning that is set forth by 
the Examiner explains why one of skill in the art in possession of these 
two references would have derived the explicitly recited claim 
limitations. No reason has been given, however, for the modification in 
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Jones et al., to cause the escalation level to be invoked for a time 
approaching the contractually-specified resolution time (emphasis 
added). 

8) Jones et al., fails to disclose, however, displaying representations of 
service tickets that have a reached a predetermined percentage of the 
time for their due date. Scheifler merely discloses an X-Window system 
and fails to address displaying a graphical display with the claimed 
representations of service tickets, as set forth in claim 1. Thus, one of 
skill in the art in possession of Jones et al., and Scheifler would merely 
have derived notifying support personnel of a deadline using an X- 
Window alert message, not the act of displaying that is explicitly recited 
in claim 1. The Final Office Action fails to set forth any plausible reason 
to explain why the skilled artisan would have hypothetically combined 
Jones et al., and Scheifler to derive displaying a graphical display 
populated with representations of service tickets that have reached a 
predetermined percentage of the time before their due date. 

Independent Claim 12: 

9) That the hypothetical combination of the cited references fails to 
disclose or render obvious first instructions to determine a deadline for 
when a problem associated with a service ticket must be resolved with 
the deadline based upon a contractually determined severity of the 
problem and a corresponding contractually required time for resolution 
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of the problem second instructions for determining a deadline 
approaching alert time at which a help desk user must be notified that 
the deadline for resolving the problem must be met. 

10) There has been no plausible reason supplied by the Examiner to 
explain why this hypothetical combination would produce instructions to 
determine a deadline approaching alert time at which a help desk user 
must be notified that a contractually-based deadline must be met. 

11) That the hypothetical combination of references fails to disclose or 
render obvious display instructions for displaying a graphical display 
populated with representations of service tickets that have reached a 
predetermined percentage of the time before their due date. The Final 
Office Action fails to set forth, however, any plausible reason to explain 
why one of skill in the art in possession of these two references would 
have derived display instructions for displaying a graphical display 
populated with representations of service tickets that have reached a 
predetermined percentage of the time before their due date. 

Independent Claim 23: 

12) The hypothetical combination fails to disclose second means for 
determining a deadline approaching alert time in which a help desk user 
must be notified that the deadline for resolving a contractually-based 
problem must be met. 
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13) That the hypothetical combination of Jones et al., Scheifler and Tsykin 
fails to disclose display means for generating a graphical display 
populated with representations of service tickets that have reached a 
predetermined percentage of the time before their due date. 

Dependents Claims 2, 13 and 24: 

14) Riley et al., fail to, however, disclose or render obvious determining a 
status update alert time to alert a help desk user that a status update 
needs to be sent to a customer (emphasis added); fails to mention 
alerting a customer or alerting a help desk user that a status update 
needs to be sent to a customer. 

15) The Final Office Action and the cited references are devoid of any 
reasoning or teaching to explain why the hypothetical combination 
would have disclosed or rendered obvious determining a first 
deadline for alerting the customer, as explicitly claimed. 

16) Jones et al., fails to disclosure in response to a determination that a 
problem has not been resolved by a deadline, determining a status 
update alert time to alert a help desk user that a status update needs to 
be sent to a customer. It is noted that neither Scheifler nor Tsykin cure 
the deficiencies of Jones et al., and Riley et al., 

Dependents Claims 4, 15 and 26: 

17) The hypothetical combination of references fails to disclose determining 
a first status update alert time to alert a help desk user that a status 
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update needs to be sent to a customer. Not only does the hypothetical 
combination fail to disclose or render obvious determining a first status 
update alert time (for the reasons set forth above), the hypothetical 
combination also fails to disclose or render obvious determining a time 
to provide a new status update to a customer, as the hypothetical 
combination fails to disclose or render obvious determining any alerts 
regarding an approaching status update. 
Independents Claim 34: 

18) The Final Office Action fails to show where any of the cited references 
disclose or render obvious that the database sends alerts to the help 
desk client alerting the help desk user that a time to take a specified 
action is approaching. 

1 9) The Office Action fails to explain why one of skill in the art in possession 
of the cited references would have derived sending an alert that a 
contractually required time to take a specified action is approaching. In 
other words, the mere combination of the references would merely 
produce a system that triggers an escalation level in response to a 
contractually-required time. The Office Action fails to set forth any 
plausible reason, however, to explain why one of skill in the art in 
possession of these references would have derived sending an alert 
about an approaching contractually-required deadline. 

Dependents Claim 39: 
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20) The Examiner fails to explain why sending an alert teaches that the 
active tickets displayed are only those that have reached predetermined 
percentage of the time before their due date. 
In response to argument 1, Examiner respectfully disagrees. The recitation the 
customer is consulted or has any input regarding the selection of the deadline 
has not been given patentable weight because the recitation occurs in the preamble. A 
preamble is generally not accorded any patentable weight where it merely recites the 
purpose of a process or the intended use of a structure, and where the body of the 
claim does not depend on the preamble for completeness but, instead, the process 
steps or structural limitations are able to stand alone. See In re Hirao, 535 F.2d 67, 190 
USPQ 15 (CCPA 1976) and Kropa v. Robie, 187 F.2d 150, 152, 88 USPQ 478, 481 
(CCPA 1951). Further, in response to Appellant's argument that the references fail to 
show certain features of Appellant's invention, it is noted that the features upon which 
Appellant relies (i.e., the customer is consulted or has any input regarding the 
selection of the deadline) are not recited in the rejected claim(s). Although the claims 
are interpreted in light of the specification, limitations from the specification are not read 
into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 
1993). 

In response to argument 2, Examiner respectfully disagrees. Appellant's 
arguments against the references individually, one cannot show nonobviousness by 
attacking references individually where the rejections are based on combinations of 
references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & 
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Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Jones et al., in view of Tsykin 
teaches the limitations as shown: Jones et al., teaches inspecting a service ticket in a 
database to determine a deadline for when a problem associated with the service ticket 
must be resolved, please see col. 3, lines 11-20; col. 5, line 60-col. 6, line 2; col. 6, line 
35-col. 7, line 61; col. 8, line 55-col. 10, line 64 which teaches time intervals 
corresponding to escalation levels for a trouble ticket; the escalation levels being 
defined based on the trouble ticket remaining unresolved for a time exceeding user 
specified time intervals; a ticket reporting and tracking system for inputting trouble 
tickets and keeping track of the ticket status in the repair process, where the information 
contained in the trouble report is stored in the ticket reporting and tracking system, data 
files are formatted into data records and send to a managing module, where the records 
are stored in memory and then evaluated against a configuration data file to determine if 
an alert should be transmitted. In addition, Jones et al., et al. teaches "the escalation 
levels being defined based on the trouble ticket remaining unresolved for a time 
exceeding user specified time intervals; (Jones et al., et al., col. 5, lines 63-65); a ticket 
reporting and tracking system for inputting trouble tickets and keeping track of the ticket 
status in the repair process (Jones et al., et al. col. 6, lines 35-37). Jones et al., et al. 
does not expressly teach that the deadline based upon a contractually determined 
severity of the problem and a corresponding contractually required time for resolution of 
the problem. However, Tsykin in an analogous art of monitoring service tickets (e.g., 
automated service level reporting) for the purpose of determining severity and required 
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time for resolution of the problem based upon a contract (Tsykin, page 10, Figure 12) as 
shown does: 

• with the deadline based upon a contractually determined severity of the 
problem and a corresponding contractually required time for resolution of 
the problem (page 10, Figure 12, which teaches a deadline based upon a 
contract (e.g., Service Level Agreement, SLA) which is old and well known 
that SLA is a negotiated agreement between two parties where one is the 
customer and the other is the service provider. Figure 12 teaches item 
"Help Desk Response" with a determined severity of the problem "Severity 
1, Severity 2 and Severity 3" and corresponding contractually required 
time for resolution of the problem "Severity 1 : < 30 min, Severity 2: < 2 hrs 
and Severity 3: < 2 hrs of next shift"); 
Therefore, it would have been obvious to one of ordinary skill in the art to modify Jones 
et al., et al., to include the teaching of Tsykin (deadlines based upon a contractually 
determined severity of a problem and corresponding contractually required time for 
resolution of the problem) because the claimed invention is merely a combination of old 
elements (determining deadlines based on contractually determined severity e.g., 
Service Level Agreement [please see Final Office action mailed on 5/6/2009 page 3, 
number 10 for the definition of Service Level Agreement (SLA)] and alerting/notifying 
help desk user based on a deadline e.g., escalation level for unresolved tickets), and in 
the combination each element merely would have performed the same function as it did 
separately (Jones et al., provides an alerting system to ensure awareness of pending 
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customer generated trouble tickets which have not been resolved for at least a 
predetermined duration corresponding to an escalation level and Tsykin disclose an 
automated service level monitoring and reporting process), and one of ordinary skill in 
the art would have recognized that the results of the combination were predictable 
(determine deadlines based on service level agreements between the help desk user 
and customers). 

In response to arguments 3, 8, 11 and 13, Examiner respectfully disagrees. 
Jones et al., teaches displaying, on a display device at the help desk, a graphical 
display populated with representations of service tickets that have reached a 
predetermined percentage of the time before their due date (col. 5, lines 51-53, which 
teaches that "the notification comprises an alphanumeric or digital page, an e-email 
message, or an X-Windows terminal display message." Where through an X-Windows 
terminal display "[t]he notification" which it "may contain various information, including 
the trouble ticket number, an escalation level, the date and time the ticket was first 
entered into the WFA system, the service type having trouble, customer name, current 
status of the ticket" (e.g., incomplete, complete, a predetermined percentage of the time 
before their due date) "and the identification (e.i. initials) of the technician involved in the 
service restoration effort."); 

Jones et al., et al. teaches the use of X-Windows system to display graphically 
the notification to a user with information related to a trouble ticket (Jones et al., et al. 
col. 5, lines 49-60). Jones et al., et al. does not expressly teach that through the X- 
Window system a graphical display is populated with representations of service tickets 
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as claimed. However, Scheifler in an analogous art of displaying user graphical 
interfaces through an X-Windows system for the purpose of enabling a user to modify 
an existing X-Windows system to populate a representation of service tickets (Scheifler 
et al, page 79, 1 st If) as shown does, where Scheifler et al. teaches that a X-Windows 
system enables a user "to build applications and to manage desktop" and it provides "a 
wide variety of application and user interfaces to be built easily" (Scheifler et al, page 
79, 1 st U) ■ 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of the invention to modify Jones et al., X- Windows system as taught by Scheifler 
et al. to graphically display a representation of tickets that have reached a 
predetermined percentage of the time before their due date because Scheifler X- 
Window system "provides high performance, high-level, device-independent graphics" 
(e.g. a graphical display). In addition, "desktop management can be custom-tailored to 
individual environments" (e.g., to display graphically a representation of tickets) 
(Scheifler et al, page 79, 1 st U). 

In response to argument 4, Examiner respectfully disagrees. Please see the 
following passage of Jones et al., which teaches that Jones et al., provides "an 
apparatus and method for monitoring customer generated trouble reports and 
generating notification to alert key personnel or management that outages (i.e. troubles) 
exist that have exceeded predefined time limits or intervals" (e.g., a deadline of a 
service ticket) (col. 1 lines 65-67-col. 2 lines 1-2) in order to "proactively ensures 
awareness" (col. 2, lines 48-49). 
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In response to argument 5, Examiner respectfully disagrees. Jones et al., 
teaches determining a deadline approaching alert time at which a help desk user must 
be notified that the deadline for resolving the problem must be met in col. 3, lines 11- 
20; col. 5, line 60-col. 6, line 2; col. 6, line 35-col. 7, line 61 that time intervals 
corresponding to escalation levels for a trouble ticket; the escalation levels being 
defined based on the trouble ticket remaining unresolved for a time exceeding user 
specified time intervals; and alerting the help desk user that the deadline for resolving 
the problem is approaching when the deadline approaching alert time is reached in col. 
11, line 13-col. 12, line 30 teaches when the alerting criteria for a ticket is satisfied, then 
notification should be sent to the appropriate management or personnel. Jones et al., in 
view of Tsykin teaches that the deadline is based upon a contractually determined 
severity of the problem as shown above in the response to argument 2. 

In response to argument 6, Examiner respectfully disagrees. Please see the 
response to arguments 2 and 5. In addition, Tsykin teaches in page 10, Figure 12, a 
deadline based upon a contract (e.g., Service Level Agreement, SLA) which is old and 
well known that SLA is a negotiated agreement between two parties where one is the 
customer and the other is the service provider wherein Figure 12 teaches item "Help 
Desk Response" with a determined severity of the problem "Severity 1, Severity 2 and 
Severity 3" and corresponding contractually required time for resolution of the problem 
"Severity 1: < 30 min, Severity 2: < 2 hrs and Severity 3: < 2 hrs of next shift". For 
Severity 1, the contractually required time for resolution of the problem e.g., deadline is 
less than 30 minutes, for severity 2 is less than 2 hours and for severity 3 is less than 2 
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hours of next shift. Therefore, Tsykin teaches deadlines based upon a contractually 
determined severity of the problem (severities 1-3) and a corresponding contractually 
required time for resolution of the problem (< 30 min). 

In response to arguments 7 and 10, that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988) and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case, Jones et al., 
provides an alerting system for proactively ensuring awareness of pending customer 
generated trouble tickets which have not been resolved for at least a predetermined 
time duration corresponding to an escalation level which sends alert to a recipient 
assigned to this escalation level. (Abstract). The predetermined alerting criteria may 
include at least one time interval. Each time interval corresponds to an escalation level, 
(col. 3, lines 16-18). Escalations levels may be defined based on the trouble ticket 
remaining unresolved for a time exceeding user specified time intervals, (col. 5, lines 
61-63). See also figures 3A and 3B. Tsykin teaches that Service Level Agreements 
(SLAs), which are a legal contract that specifies the minimum expectations and 
obligations that exist between a service provider and a service customer [please see 
Final Office action mailed on 5/6/2009 page 3, number 10 for the definition of Service 
Level Agreement (SLA)] Table 12 illustrates that for each contractually determined 
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severity (1, 2 and 3), a corresponding required time for resolution (e.g., user specified 
time intervals, 0-30 min, 0-2 hours). Therefore, it would have been obvious to one of 
ordinary skill in the art at the time of the invention to modify Jones et al., escalation level 
to be invoked for a time approaching the contractually-specified resolution time as 
taught by Tsykin because Service Level Agreements are based on user specified time 
intervals (e.g., minimum expectations and obligations) in order to solve trouble tickets. 
See also the response to arguments 2, 4, 5 and 6. 

In response to arguments 9 and 12, Examiner respectfully disagrees. Please 
see the response to arguments 2, 4, 5, 6 and 7. 

In response to argument 14, Examiner respectfully disagrees. Jones et al., 
teaches determining a status update interval for the service ticket (col. 7, lines 19-39 
teaches the application receiving reports on a time interval); and responsive to a 
determination that the problem has not been resolved by the deadline, determining a 
first status update alert time to alert the help desk user (vol. 7, lines 19-61 teach that the 
interval should be predefined and publicly known because a configuration data file for 
alerting contains time periods for alerting based upon this interval where once the time 
duration of other alerting criteria has been satisfied, the module requests an alert to be 
sent to the appropriate personnel). Jones et al., et al. does not expressly teach alerting 
the help desk user to then send a status update to the customer. However, Riley et al. 
in an analogous art of implementing service desk capability for the purpose of sending a 
status update to the customer (paragraphs 136-137), Riley et al. teaches alerting the 
help desk user to send a status update to the customer (paragraphs 136-137 teach the 
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exceeding a target time and sending a notification to a personnel who will be assign the 
problem, "[s]ince as assignment is made through notification, more than one party (the 
assignee) may be notified. Fig. 10 suggests which person to notify", please see Figure 
10 "Notification Addressee" "Tier 1 logger and/or customer" where paragraph 144 
teaches that as service requests are escalated, or as they exceed target time and are 
assigned a higher tier operator in which notifications are sent to the new personnel, the 
Service Desk, or the personnel, needs "to communicate the status with the customer on 
a regular basis and update the status constantly with the tracking tool". 
It would have been obvious to one of ordinary skill in the art to include in the method 
monitoring progress of customer generated trouble tickets of Jones et al., et al. the 
ability to send a status update to the customer in response to ticket escalation as taught 
by Riley et al. since the claimed invention is merely a combination of old and well known 
elements, and in the combination, each element merely would have performed the 
same function it did separately, and one of ordinary skill in the art would have 
recognized that the results of the combination were predictable. 

In response to argument 15, that the references fail to show certain features of 
Appellant's invention, it is noted that the features upon which Appellant relies (i.e., 
determining a first deadline for alerting the customer) are not recited in the rejected 
claim(s). Although the claims are interpreted in light of the specification, limitations from 
the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1 181, 26 
USPQ2d 1057 (Fed.Cir. 1993). 
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In response to argument 16, Examiner respectfully disagrees. Please see the 
response to arguments 2, 4, 5, 6, 7 and 14. 

In response to argument 17, Examiner respectfully disagrees. Please see the 
response to argument 14. In addition, Jones et al., et al. teaches responsive to a 
determination that the problem has not been resolved after a time has passed, 
determining a time to alert the help desk user as recited above in claim 1 . However, 
Jones et al., et al. does not teach the time being a status update time or determining a 
time to alert the help desk user that a time to provide a new status update to the 
customer is approaching and alerting the help desk user prior to the time to provide the 
new status update. Riley et al. teaches time being a status update time and determining 
a time to alert the help desk user that a time to provide a new status update to the 
customer is approaching and alerting the help desk user prior to the time to provide the 
new status update (paragraphs 77-82 teach reminding personnel when to escalate 
incidents, when to provide status information to users, and when service levels are not 
being met; Fig 12 teaches notifying or alerting of escalation and contacting the customer 
as part of the whole service request escalation process, or rather alerting of escalation, 
which includes a new status update, see also paragraph 144 "[a]s service requests are 
escalated, the Service Desk needs to communicate the status with the customer on a 
regular basis and update the status constantly with the tracking tool"). 
It would have been obvious to one of ordinary skill in the art to include in the method 
monitoring progress of customer generated trouble tickets of Jones et al., et al. the 
ability to alert of a status update time and providing new status updates to the customer 
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as taught by Riley et al. since the claimed invention is merely a combination of old and 
well known elements, and in the combination, each element merely would have 
performed the same function it did separately, and one of ordinary skill in the art would 
have recognized that the results of the combination were predictable. 

In response to argument 18, that the references fail to show certain features of 
Appellant's invention, it is noted that the features upon which Appellant relies (i.e., that 
the database sends alerts to the help desk user that a time to take a specified 
action is approaching) are not recited in the rejected claim(s). Although the claims are 
interpreted in light of the specification, limitations from the specification are not read into 
the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 
Further, the database stores tickets and the monitor server is the one who sends alerts 
as disclose in claim 34. Jones et al., teaches that the database stores tickets and 
information regarding ticket types, ticket severities; for actions to be performed for each 
of the ticket types and ticket severities (col. 1 1 , lines 35-66 teach the report information 
containing information including type of service required, or ticket type, ticket duration, 
status, position, escalation levels, or time for actions to be performed for each ticket, 
which includes ticket type; col. 15, lines 35-44 teach that the severity of repair work can 
be indicated in the report as well) and the monitoring server monitors tickets in the 
database, determines when time for actions are approaching, and sends alerts to the 
help desk client alerting the help desk user that a time to take a specified action is 
approaching (col. 3, lines 1 1-20; col. 5, line 60-col. 6, line 2; col. 6, line 35-col. 7, line 61 
teaches time intervals corresponding to escalation levels for a trouble ticket; the 
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escalation levels being defined based on the trouble ticket remaining unresolved for a 
time exceeding user specified time intervals; col. 11, line 13-col. 12, line 30 teaches 
when the alerting criteria for a ticket is satisfied, then notification should be sent to the 
appropriate management or personnel "(iii) validating the alerting time interval or period 
for each ticket based on the configuration data file of the service center specified in the 
ticket; (iv) flagging as an alert if the ticket meets the defined alerting criteria; and (v) 
sending the flagged ticket to the alerting or paging process." See also figures 3A and 
3B); 

In response to argument 19, that there is no suggestion to combine the 
references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988) and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case, Jones et al., 
provides an alerting system for proactively ensuring awareness of pending customer 
generated trouble tickets which have not been resolved for at least a predetermined 
time duration corresponding to an escalation level which sends alert to a recipient 
assigned to this escalation level. (Abstract). The predetermined alerting criteria may 
include at least one time interval. Each time interval corresponds to an escalation level, 
(col. 3, lines 16-18). Escalations levels may be defined based on the trouble ticket 
remaining unresolved for a time exceeding user specified time intervals, (col. 5, lines 
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61-63). See also figures 3A and 3B and col. 12, lines 19-33. See also the response to 
argument 18. Riley et al., teaches that "the operator analyzes the service request in 
order to prioritize it. The resulting prioritization is used to classify the request against all 
other requests made by the Service Desk customers and determines the speed in which 
the service request should be handled" (e.g., contractually required times) "(according 
to defined Service Level Agreements or SLAs)." Further, "[t]he type of information 
necessary for assigning priority can include: [t]he service request's impact, the service 
request's severity, the criticality of the business function affected, the resolution 
urgency. The meaning of each of these terms will be adjusted to fit the organization, but 
each should be clearly defined and documented" (e.g., Service Level Agreement or 
SLAs) which is old and well known that SLA is a negotiated agreement between two 
parties where one is the customer and the other is the service provider where the level 
of service is formally defined (Riley et al, U 0116-0121). Therefore, it would have been 
obvious to one of ordinary skill in the art at the time of the invention to send an alert 
about an approaching contractually required deadline (e.g., service level agreements), 
as taught by Riley et al., to improve Jones et al., thereby giving the predictable result of 
setting out "the services to be performed and the target service levels to be achieved. 
These SLAs are designed for the user community and are written with the Service Desk 
customers in mind." (Riley et al., H 0032). 

In response to argument 20, Examiner respectfully disagrees. Please the 
response to argument 3 and the following passage of Jones et al., which teaches 
wherein the active tickets displayed are only those that have reached a predetermined 
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percentage of the time before their due date (col. 1 lines 65-67-col.2 lines 1-2 and col. 
2, lines 23-34, teaches that a notification is sent through the X-Windows system which 
is fully customizable as discussed above in the response to argument 3, "to alert key 
personnel or management that outages (i.e. troubles) exist" (e.g., active tickets) "that 
have exceeded predefined time limits or intervals" (a predetermined percentage of the 
time before their due date). Jones et al. teaches that the notification display only those 
ones that have exceeded a predefined time limit or intervals. See also col. 5, lines 41- 
44"provides a management tool to alert recipients of trouble tickets having exceeded 
predefined tie interval(s) without service resolution or repair". 
(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 

/Nadja Chong/ 
Examiner, Art Unit 3623 

Conferees: 
/Beth V. Boswell/ 

Supervisory Patent Examiner, Art Unit 3623 
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Vincent Millin /vm/ 

Appeals Conference Specialist 



